home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 8698 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.4 KB
  1. Path: news.crystalball.com!news
  2. From: Larry Weiss <lfw@oc.com>
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Tradition or what?
  5. Date: Tue, 05 Mar 1996 09:25:05 -0600
  6. Organization: crystalball.com
  7. Message-ID: <313C5CD1.1209@oc.com>
  8. References: <4g0elg$mdr@redstone.interpath.net> <4h0bbo$c0q@fohnix.metronet.com> <4h7ce0$ojd@news.interpath.net> <4h85sm$lm0@texas.nwlink.com> <danpop.825961872@rscernix>
  9. NNTP-Posting-Host: external.oc.com
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.0 (Win16; I)
  14.  
  15. Dan Pop wrote:
  16. > 
  17. > In <4h85sm$lm0@texas.nwlink.com> Teresa Reiko <tjr19@mail.nwlink.com> writes:
  18. > >Here are the three worst Microsoft coding rules, in my opinion at least:
  19. > >Every line of code must contain a comment.
  20. > >Any number greater than 2 must be a named constant.
  21. > >No procedure may be longer than 25 lines.
  22.  
  23.  
  24. > Actually, the second rule is quite good (except that '2' should be replaced
  25. > by '1' :-)  Magic constants embedded in the code are a huge nuisance
  26. > for maintenability.  If you have to change an explicit (aka magic) constant
  27. > in a piece of code, how can you be sure that you aren't going to break
  28. > anything?  By changing a macro definition, you _know_ that you won't
  29. > break anything, because all the dependencies of that macro will be
  30. > automatically taken care of by the compiler (and your "make" utility). 
  31.  
  32. I agree that there are good uses for giving a literal a name, and using
  33. that name instead of repeated usage of the literal, but to make a
  34. mandate that even if the literal were referenced only once you must give
  35. it a name would seem too extreme.
  36.  
  37. In the environment of named literals, I must always refer back to the 
  38. mapping.   Now you would say, fine, just deal with the abstraction and
  39. not the actual value, but what I lose is the ability to readily make
  40. comparisons to other literal values when they just have names.   I can't
  41. readily see the proportions and other relative associations that are
  42. usually there in the code.   I no longer have an immediate grasp of
  43. the qualities of "small" or "large"  or maybe "unusually large" if all
  44. is hidden in an abstract, one string fits all name.   When there are errors
  45. in the #define of the literal's name, these can be very hard to detect,
  46. as they are hidden away in the header file.   
  47.  
  48. Anyway, I'm just saying teach the concept of named literals and then let
  49. the programmer make the decision on a case by case basis.
  50.